Appln. No. 10/674,778 
Response dated 27 October 2010 

to Office Action of 27 May 2010 
Docket No. CA920020061US1 

REMARKS/ARGUMENTS 

These remarks are made in response to the Office Action of 27 May 2010 (Office 
Action). This response is filed after the expiration of the 3-month shortened statutory period and 
a one month extension is believed to be due. The Examiner is authorized to charge the extension 
fee and any deficiencies or credit any overpayments to Deposit Account No. 50-3610. 

I. 35 U.S.C. § 112. second paragraph REJECTION 

Claims 17-20 are rejected due to being indefinite for bring indefinite for failing to 
particularly point out and distinctly claim the subject matter which Applicant regards as the 
invention. 

The Examiner has objected to the term "well-defined" as a relative term. Under MPEP 
2173.05(b): 

The fact that claim language, including terms of degree, may not be precise, does 
not automatically render the claim indefinite under 35 U.S.C. 112, second paragraph. 
Seattle Box Co., v. Industrial Crating & Packing, Inc., 731 F.2d 818, 221 USPQ 568 
(Fed. Cir. 1984). Acceptability of the claim language depends on whether one of ordinary 
skill in the art would understand what is claimed, in light of the specification. 

When used in context of a Web service being a "well-defined", self-contained component 
that encapsulates specific functionality, which is made available to other computing applications 
over a network by a web service invocation using a Simple Object Access Protocol" the term 
"well defined" is understandable by one of ordinary skill. 

In fact, the term "well-defined" is commonly used in the field in association with web 
service. For example, 

• insdn.imcrosoft.coin/en-us/..yins531032(VS.85).aspx 

"Web Services provide well-defined interfaces, or contracts, that describe the services 
provided." 

• http://www.service-architecture.coiii/web-services/articles/service- 
oriented_architecture_soa_definition.htiiil 
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"A service is a function that is well-defined, self-contained, and does not 
depend on the context or state of other services." 

• www.oracle.coin/technetwork/articles/javase/index-142519.htinl 

"A service is an implementation of a well-defined business functionality" 

Thus, it can be seen from the above examples, that the term "well-defined" is often used in 
context of Web services and is understood in this context by one of ordinary skill. Consequently, 
Applicants respectfully request the 1 12 rejections to claims 17-20 be withdrawn. 

II. 35 U.S.C. § 103(a) REJECTIONS 

Claims 1-15 and 18-20 are rejected as being unpatentable over Stelting (2004/0030740) 
in view of Bowman- Amuah (6,640,249) and view of Nguyen (2003/0172145). 

A. Claimed limitations are not taught 

The Applicants' claims include a limitation for providing a Web service interface for a 
billing service in a distributed network. The primary reference (Stelting) lacks teachings of 
providing a billing service as a Web service. None of the other cited references (Bowman, 
Nguyen) cure the deficiencies of Stelting. 

Stelting teaches dynamically combining two (or more) services to create a custom Web 
service. In other words, Stelting is teaching that services can be treated like discrete building 
components (e.g.. Lego blocks) that can be combined at will. 

One example of Stelting being used, is shown by FIG. 8 (included below) 
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FIG. 8 shows a billing server 740 that provides billing service 742. From Stelting's teachings, 
it is clear that: (last sentence para 0043) 

746). Ileoce, to access and run ibe services 734, 742, 754, 
service rec|u.esis or methods of i«voMj3g the se;rvices 734, 
742, 754 need to be cxsmpliaot with tbe corresponding 
iotertos 7m, 746, 758. 

The interfaces 738, 746, and 758 are defined in para 0043 as: being specific to the shipping 
server, as a first public interface (which is a standard interface publicly available), and a second 
public interface 748 (which is another standard interface that is publicly available but that is 
different from the interface 746). None of the interfaces 738, 746, 758 are defined as being Web 
service interfaces. 
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In fact, they are explicitly contrasted with the interface of Web service 762. Further, it is noted 
that system 710 has to explicitly locate the services 734, 742, 754 (first sentence of para 0044). 
It then creates adaptors 766, 770, 776 for invoking the services 734, 742, 754 via the interfaces 
738, 746, 758. Stelting states that the services 764, 768, 772 are coordinating classes (last 
sentence para 0044). 

The novel steps of Stelting are taken to "allow services 764, 768, and 772 to be combined 
and offered as a Web service 762. Thus, the expUcit teachings of Stelting are for a Web service 
762, which is a combination of functions provided by a shipping service, billing service, and a 
calculator service. Nowhere does Stelting state or imply that the billing service 742 is provided 
as a Web service. Indeed, an explicit statement is made that the functions of service 742 cannot 
be accessed or run except through interface 746, which is not defined as a Web service interface. 

Thus, no explicit (or inherent defined by MPEP 2112 IV) teachings of Stelting are for 
billing services that are to be provided as Web Services. The claims of Stelting clarify this, for 
Example, claim 1 of the allowed case (patent issued as 7, 266, 582 on Sept 4, 2007) includes: 

1. A computer-based method for generating a Web service for use over a digital 
communications network, comprising: 

identifying first and second service components adapted for providing a first and a 
second functionality for inclusion in a new Web service, wherein the first and second 
service components comprise callable methods not configured as Web services on the 
digital communications network as the callable methods lack invoking rules and transport 
structure to configure the callable methods as Web services for use over the digital 
communications network; 

generating a single description of the new Web service including a calling 
structure based on the first and second service components; creating a transport structure 
for requests to and responses from the new Web service suited for data transfer over the 
communications network; 

and advertising the new Web service on the communications network. 

From the above claim, it is clear that more than one services are being combined by Stelton (such 
as the shipping service, the billing service, and the calculator service) to generate a single new 
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service, which is a Web service. Where the services being combined, are explicitly are not 
configured as Web services. 

Turning to claims 1, 6, 11, 16 : the following limitations are claimed 

a web service interface, which is implemented within software stored on a 
tangible computer readable medium, defined for a billing service, said web service 
interface being adapted for coupling to a billing engine, said billing engine residing on a 
computing device in said distributed network and being adapted to perform said plurality 
of billing functions, said web service interface comprises a plurality of application 
programming interfaces, each of said application programming interfaces being 
associated with one of said bilhng functions and being implemented such that the biUing 
function associated therewith is performed after a web service invocation that conmiands 
performance of said billing function is received by said web service interface; and 

said web service interface being used to provide said billing service as a web 
service that is configured to be invoked by said computing applications in said distributed 
network. 

For the "billing service" of the claims, object 742 is cited. As previously noted, this object 742 
must be accessed via public interface 746, which is not a Web service interface. The only Web 
service in system 700 is service 762, which is a combined service that utilizes service 734, 742, 
and 754. 

No mention is made that the cited interface 746, 742) is a Web service interface, and the 
specification of Stelting defines it as a standard public interface. From the allowed claims, this 
would be interpreted as an "callable methods not configured as Web services". 
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Para 0040 is also cited, which talks about the "new Web service" which would be service 762 
generated per system 710. 

Additionally, stated another way, if the services 734. 742, and 754 were standard Web services, 
they could simply be invoked and combined without requiring the teachings of Stelting (system 
710 and items 764-776 would not be needed). This is one of the advantages of using Web 
services since they are self-defined platform independent, etc. Stelting is designed to deal with 
other types of services, since (para 0009, Stelting) Stelting admits that few Web services were 
available so that other types of services (such as shipping service 734, billing service 742, and 
calculator service 754) can be used to construct new Web services (see para 0010). 

Hence, the providing of billing services as Web services, is not explicitly or inherently (note 
MPEP 2114 IV states that for inherency a thing must be "necessarily present" and that "a mere 
possibly of existence is not sufficient) taught by Stelting. 

Further, none of the combined references (Bowman-Amuah, Nguyen) cure this deficiency. 
Since each of the claimed limitations claim providing billing services a Web services, each of the 
claims include non-taught limitations. On this basis, the 35 USC 103 rejections to the claims 1- 
20 should be withdrawn, which action is respectfully requested. 

Claims 17-20 

Note, applicants have taken the limitations previously in claims 17-20 and placed them in 
dependent claims 2, 7, 12, and 16 

Applicants note that even the Web service 762 (which is a combined service) uses a set of 
adaptors and internal classes, to communicate to the services 734, 742, 754 via the interfaces 
738, 746, 758. Applicants have clarified in dependent claim 17-20 that the claimed "Web 
interface is directly coupled to billing engine" as supported by page 8, line 25. Further, the 
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rating service web interface is directly coupled to the rating engine, as supported by page 11, In 
1. These amendments are fully supported by the specification, and are in direct conflict with 
explicit teachings of Stelting (last sentence para 0043, and use of items 764-776). Thus, these 
claims should be allowable over the cited references on this basis as well. 

Claim 1 also includes the limitation of: 

a plurality of object classes which are implemented within software stored on a tangible 
computer readable medium, each of said object classes defining objects for storing data utilized 
by said billing engine and for communicating said data to said billing engine through at least one 
implemented application programming interface of said web service interface, 

When read in context, this means that the parameters passed via a Web service interface are 
object classes. So WebService A (object A, object B . . .. ) shows that parameters that are objects 
are passed via the Web service. This is not a "normal" way to use objects, and applicants are not 
aware of this practice being used before the effective date in conjunction with Web services. 
Turning to Stelting, the interfaces 734, 746, 758 must be used. These are defined as standard or 
proprietary interfaces. No mention that these interfaces use classes is taught. It wouldn't make 
sense to use objects classes as claimed, as it would require the changing of parameters of Web 
service 762 and interfaces 738, 746, and 758, which are not permitted to be changed by the 
creator of the Web service4 760 (using system 710). 

For this limitation, col 10, In 44-55; col 10, In 67-col 11, In 1; col 12, In 37-59; col 106, In 59-62; 
col 123, In 34-37 are cited). 

The cited portions of Bowman, do not teach that objects are to be passed as parameters within 
Web services. Since this limitation is not taught by any cited reference, and is not known in the 
field, the rejections should be withdrawn on this basis, which action is respectfully requested. 
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Claim 2 

The claim specifically states that a Web service interface is extensible. The examiner 
cites a different architecture (an object oriented one), which is extensible and then "implies that a 
given architecture can be adaptable. This is an improper rejection. 

Stated differently, STelting teaches a Web service interface 762, which is not extensible, as 
noted on page 7 of the Action. Bowman does not disclose an extensible Web service interface. 
Thus, this limitation is not taught by the combination of references, and should be withdrawn on 
this basis. 

Claim 3 

A conclusory statement (no references or specific citations provided) that Nguyen (124 pages 
long) teaches the creation of billing account, billing events .. is provided. 

Applicants do not know what specific sections of Nguyen are meant to be teach the claimed 
limtations. However, the only billing function of Nguyen is one used by an internet service 
provider. None of these have anything to do with services provided (ASP's ) by the internet 
service provider. 

Hence, it is known how an internal billing system is related to the Web service provided to 
others, which is claimed. If maintaining this rejection, please elaborate providing specific 
references to Nguyen and providing a rationale on the record for why internal record keeping is 
being cited for an externally provided service, which is not taught by Nguyen. 

This limitation should be withdrawn on this basis. 

Claim 4 
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A conclusory statement (no references or specific citations provided) that Nguyen (124 pages 
long) teaches the limitations of claim 4. 

Applicants do not know what specific sections of Nguyen are meant to be teach the claimed 
limitations. However, the only billing function of Nguyen is one used by an internet service 
provider. None of these have anything to do with services provided (ASP's ) by the internet 
service provider. 

Hence, it is known how an internal billing system is related to the Web service provided to 
others, which is claimed. If maintaining this rejection, please elaborate providing specific 
references to Nguyen and providing a rationale on the record for why internal record keeping is 
being cited for an externally provided service, which is not taught by Nguyen. 

This limitation should be withdrawn on this basis. 

Claim 5 

This claim cites that object classes are established for at least three of: billing accounts, billing 
events, billing rate packages, billable services, billing subscriptions, and billable service 
instances. 

Some random teachings about object oriented are cited from Bowman. Applicants did not invent 
the concept of object oriented programming, and have not claimed it. Bowman does not teach 

using objects as web service parameters, which is claimed in context (as previously mentioned). 
Bowman does not teach any of the six specific object classes, which are claimed. 

Thus, this claimed limitation is not taught by Bowman, and the rejection should be withdrawn on 
this basis. 
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Claim 16 

As already mentioned, Steltin fails to teach providing a billing function as a Web service, 
as claimed. 

Additionally, the fact that Nguyen bills clients for an ISP service in a certain manner 
(para 0017) has nothing to do with providing billing services to others, which is claimed. 

Cameron details a type of billing system, which is not a Web service, or provided to 
customers. So effectively a way that an ISP bills their own customers (which could be 
implemented to include some of Cameron's teachings) provides no meaning teachings for a Web 
service that is provided to permit others to implement their own billing strategies for their own 
company. The asserted combination fo Nguyen and Cameron doesn't make sense in context. 

Hence, the claimed limitations asserted as not taught by Stetlgin: 

"executing the billing function, create a billing account, delete a billing account, create a 
record, obtain the status, obtain an invoice" are lacking in the combination, and the rejections 
should be withdrawn on this basis. 

The references are not properly combined 

Throughout the office action, the rationale provided for combining the references was 
that it would be obvious to try, per KSR (E). This rationale has been misapplied. 

The "obvious to try" test can be grounds for finding an invention to be obvious, in that 
"[w]here there is a design need or market pressure to solve a problem and there are a finite 
number of identified, predictable solutions, a person of ordinary skill has good reason to pursue 
the known options within his or her technical grasp. If this leads to the anticipated success, it is 
likely the product not of innovation but of ordinary skill and common sense." 

Supreme Court's instruction, that this rationale is only appropriate when there is a 
recognized problem or need in the art; there are a finite number of identified, predictable 

solutions to the recognized need or problem; and one of ordinary skill in the art could have 
pursued these known potential solutions with a reasonable expectation of success... Courts 
appear to be applying the KSR requirement for "a finite number of identified predictable 
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solutions" in a manner that places particulai- emphasis on predictability and the reasonable 
expectations of those of ordinary skill in the art. 

The first problem with the asserted rational is the statement of the "problem". Before the 
rational can be applied, a problem has to be defined, where there is market pressure to solve this 
known problem. This stated problem has to have a set of finite solutions, which the Examienr 
can enumerate. This enumeration has not been performed in the Action. If maintining this 
rejection, please provide an enumerated listing of the finite number of solutions for the stated 
problem(s). 

The problem stated in page 6 of the Action is: 

"A problem or need to leverage professional expertise from outsourcing" 

By definition, outsourcing refers to "Outsourcing often refers to the process of subcontracting to 
a third-party." The following solutions, would apply to the "need to leverage professional 
expertise: 

1) Hire an outside agency to perform billing 

2) Hire contract employees (1099) to "outsource" this function 

3) Train employees through an outsourced source to leverage professional expertise 

4) Use COTS (developed by others - experts) software 

5) Perform a joint project with another similarly minding company to share costs and 
resources 

6) Trade services with another company . . . 

This list could go on and on. The APS referred to by Nygen are (para 0009) include: 
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loternet most ofteo oiitsoiirce Informatioa TeclHiology (11} 
fiinctioas to ASPs^ to save time and money. For example^ 
some ASPs m the market today are FeopfeSDft®^ TIBCO™^ 
VerticalNet™, AIX?#, and Oracle. ISPs provide lotemet 
access and services to biisiness aod residential sutedbers. 
For emmple, some ISPs io tbe market today are America 
Oolme''' (Am.^) Mm Bmadbaod Mtemet^^, Mmd- 
spriog'^'^^^ and EartltliEik/^'^. 

Having seen the above "problem" an almost infinite (and certainly not finite) set of solutions 
result. The Action's statement that "outsourcing functions verses maintaining them in-house) 
being one of the finite set of solutions for the problem, is incorrect. If maintaining this rational, 
please enumerate the "finite set of solutions that are involved with the problem. The finite set 
cannot be the set of: 

1) Do the things the Applicants claims do 

2) Do something else 

Which is effectively the finite set of solutions listed. This is an improper use of KSR (E), and 
the rejections should be withdrawn on this basis. 

NEXT . . . even beginning with the stated solution of: 

"outsourcing functions verses maintaining them inhouse) 

This can be preformed "using conventional techniques for outsourcing functions. This can 
include a contractor using their software to perform the function. It can include using online 
software. There is no "motivation" or market pressure inherent in this statement to develop a 
new solution for the problem. The "old" solution satisfied the problem as stated, just fine. 
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Please provide proof that conventional solutions to outsourcing were lacking and that a "market 
pressure or need for the problem existed. Then provide proof that existing solutions did not 
satisfactory resolve this need. 

Then we need to have evidence that someone elaborated on the possible solutions to outsourcing, 
which included Web services, among a small finite set of solutions. 

Turning to claim 16 

No rationale to combine is provided "other than known techniques are applied to yield 
predictable results. This is a conclusioary statement and not a motivation to combine. The 
rejections to claim 16 should be withdrawn on this basis, which action is respectfully requested. 

Applicants note, according to MPEP 2143.01 Rejections on obviousness cannot be sustained by 
mere conclusory statements; instead, there must be some articulated reasoning with some 
rational underpinning to support the legal conclusion of obviousness. This has recently been 
clarified by the Board of appeals in IN Re Linzer (Appeal 2009-001858), which emphasizes that 
a generic benefit is not proper motivation, when no explanation is provided that the cited art 
actually provides that benefit. The benefited asserted as the motivation to combine must be 
taught by references on the record. 

This holding is consistent with internal USPTO rules established for Examiners (referring to 
USPTO internal document "Formulating and Communicating Rejections Under 35 USC 103 For 

Applications Directed To Computer-Implemented Business Method Inventions", a copy of 
which is available at htta://w-vvw.uspto.gov/patents/resources/methods/bustTieth103rej.Jsp#V . Applicants note 

examples 17-19, showing improper motivation based on hindsight, which is consistent with In 
Re Linzer and MPEP 2143.01. 
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In the specific instance, the motivation to combine is believe to be similar to Example (17, 18, 
19) in that cited motivation (is a general motivation statement including a general non- taught 
benefit; provides a motivation contrary to the stated purpose of the reference; is not directed to 
claim differences). 

< modify the above para to select one, arguments specific to case here > 

Should the Examiner disagree with the state of the law expressed above, please state so in a 
subsequent response along with your reason for disagreement so that Applicants and the 
Examiner can progress in prosecution from a common understanding, which should lead to an 
expedited prosecution. Should the Examiner agree with the state of the law, but disagree with 
how the applicants understand it in application to this specific case, please state so in a 
subsequent action and provide reasoning why your articulated reasoning and underpinnings 
previously expressed are sufficient under to MPEP 2143.01, and are distinguishable from 
Example (17, 18, 19). In absence to the above being properly expressed. Applicants respectfully 
request withdrawal of the MPEP 103 rejections since no proper rational to combine the 
references has been provided. 

CONCLUSION 

The invention as claimed (Claims 1-20) should be in allowable condition. The 
Applicants request that the Examiner call the undersigned (954-745-0373) if clarification is 
needed on any matter within this Reply, or if the Examiner believes a telephone interview would 
expedite the prosecution of the subject application to completion. 

Respectfully submitted. 

Date: 27 October 2010 /Brian K. Buchheit/ 

Brian K. Buchheit, Registration No. 52,667 
PATENTS ON DEMAND 
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Customer No. 57736 
4581 Weston Road, Suite 345 
Weston, FL 33331 
Telephone: (954) 745-0373 
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